Skip to main content
This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

Previous Next

Interesting results of testing...

I just tested this with my Time Zone System database. The db has agents that read the Time Zone Database from IANA (Internet Assigned Numbers Authority) via FTP, creates 5325 documents from the data (currently,) and then processes those documents to create current and historic time-zone and daylight saving data. One agent does the downloading and document creation, and a second agent processes the data.

I made a copy of the processing agent and replaced all the document/field references with entry/ColumnValues references. Every test was with a fresh copy of a preloaded db (that is, first agent already ran.)

On 7.0.3 client (2.8GHz AMD, but on an old hard drive)
3 1/2 minutes for document/field based code
30 minutes for entry/ColumnValues based code (yes...30 minutes.)

Both 8.5 tests were on a 1.33 GHz Intel Atom (but with similar hard drive)

On 8.5.3 server, agents executed from the console...
44 seconds document/field based code
49 seconds entry/ColumnValues based code

On 8.5.3 client
45 seconds document/field based code
49 seconds entry/ColumnValues based code


So...I stand corrected on my assertion that a document/field read is much faster than an entry/CV read. It's still faster, but only by 10% (it wouldn't surprise if, behind the scenes, Lotus simply replaced the CV read with a document/field read for non-computed values.)

Like you, I've heard for a long time that using ColumnValues was supposed to be faster. Truth be told, I never really used ColumnValues because the performance issue never came up and I find that document lookups aren't susceptable to issues created by view changes (so...one less thing to break.) But for various reasons I decided that on the Time Zone processing agent, I would use ColumnValues. I couldn't understand why in the world the agent was taking so long to run. In frustration, I rewrote the agent with document lookups. Why? Because there simply wasn't anything else to blame for the slow speed. I was shocked when the agent ran in a 10th of the time. I coded this on R7 but I did test it on R8.5.1. I later upgraded my R8 client and server, but never tested it again.

So it's good to know that ColumnValues is running much, much faster. But as the numbers show, the document lookup is still faster.

More Info
The documents in this db are really nothing more than rows of a table. The docs created by the first agent have 9 fields and that's it. The views show all the data, sort by one or two columns, and there's no categorization. Every column is a simple field assignment. Since I knew I wouldn't be changing the structure of the view or documents, I figured I'll use ColumnValues for the best performance. Little did I know!


Feedback response number WLOO94A6B7 created by ~Julia Feztoosterader on 01/25/2013

Subscript Out of Range (~Michelle Xange... 24.Jan.13)
. . The number of elements in column.va... (~Fred Xanjumima... 24.Jan.13)
. . . . Agree, but only partly (~Ned Nimfanakon... 24.Jan.13)
. . . . . . Interesting results of testing... (~Fred Xanjumima... 25.Jan.13)
. . . . . . . . Very interesting! (~Ned Nimfanakon... 25.Jan.13)
. . . . . . . . . . Few more things to note (~Fred Xanjumima... 25.Jan.13)




Printer-friendly

Search this forum

Member Tools


RSS Feeds

 RSS feedsRSS
All forum posts RSS
All main topics RSS